Topbike tidsestimering med hjälp av intermediate COCOMO (hämtad från Wikipedia)
Antaganden:
Arbetskostnad
7000€/pers/mån (alla i projektet)
Ursprungligt program
10000 rader kod
Behov av modifiering i huvudprogrammet
1000 rader kod
Reparationsmodul (nytillverkning)
1000 rader kod
Produktivitet (modifiering) rader kod/månad
1000 rader kod
Produktivitet (nyskapande) rader kod/månad
1000 rader kod
Beräkningsformel
E=EAF*a*(KLoC)(b)
Arbetstid (huvudprogrammet)
1 månad
Arbetstid (reparationsprog.)
3 månader
Huvudprog.
Cost Drivers
Huvudprogrammet
Ratings
EAF =
0,667725
Product attributes
Very Low
Low
Nominal
High
Very High
Extra High
Required software reliability
0,75
0,88
1
1,15
1,4
a =
3,2
Size of application database
0,94
1
1,08
1,16
b=
1,05
Complexity of the product
0,7
0,85
1
1,15
1,3
1,65
KLOC =
1,00
Hardware attributes
Run-time performance constraints
1
1,11
1,3
1,66
Memory constraints
1
1,06
1,21
1,56
E =
2,136718
Volatility of the virtual machine environment
0,87
1
1,15
1,3
Required turnabout time
0,87
1
1,07
1,15
Svar:
Personnel attributes
Tidsåtgång för huvudprogrammet: 2,14 arbetsmånader
Analyst capability
1,46
1,19
1
0,86
0,71
Kostnad för huvudprogrammet: 15000 €
Applications experience
1,29
1,13
1
0,91
0,82
Software engineer capability
1,42
1,17
1
0,86
0,7
Virtual machine experience
1,21
1,1
1
0,9
Programming language experience
1,14
1,07
1
0,95
Project attributes
Application of software engineering methods
1,24
1,1
1
0,91
0,82
Use of software tools
1,24
1,1
1
0,91
0,83
Required development schedule
1,23
1,08
1
1,04
1,1
Tidsestimering:
Reparationsmodulen
Reparationsprog.
Cost Drivers
Ratings
EAF =
0,516957
Product attributes
Very Low
Low
Nominal
High
Very High
Extra High
Required software reliability
0,75
0,88
1
1,15
1,4
a =
3,2
Size of application database
0,94
1
1,08
1,16
b=
1,05
Complexity of the product
0,7
0,85
1
1,15
1,3
1,65
KLOC =
1,00
Hardware attributes
Run-time performance constraints
1
1,11
1,3
1,66
Memory constraints
1
1,06
1,21
1,56
E =
1,654263
Volatility of the virtual machine environment
0,87
1
1,15
1,3
Required turnabout time
0,87
1
1,07
1,15
Svar:
Personnel attributes
Tidsåtgång för reparationsprogrammet: 1,65 arbetsmånader
Analyst capability
1,46
1,19
1
0,86
0,71
Kostnad för reparationsprogrammet: 11000 €
Applications experience
1,29
1,13
1
0,91
0,82
Software engineer capability
1,42
1,17
1
0,86
0,7
Virtual machine experience
1,21
1,1
1
0,9
Programming language experience
1,14
1,07
1
0,95
Project attributes
Application of software engineering methods
1,24
1,1
1
0,91
0,82
Use of software tools
1,24
1,1
1
0,91
0,83
Required development schedule
1,23
1,08
1
1,04
1,1
Som det syns i tidsestimenringen så verkar de olika projekten vara lite snålt tilltagna för att man genast skall få en vinst från projektet, men å andra sidan så kommer projektet att bringa in 15000£ varje år som egentligen kan anses vara en del av detta projekt. Därför kan det anses vara en investering att ta hand om detta projekt fastän det inte i början verkar bli lönsamt. Som vi har tänkt oss skall huvudprojektet ta ca 1 månad i anseende och sysselsätta två arbetare på heltid. Reparationsmodulen i sin tur verkar bli ett mindre projekt som en person själv får ha hand om och som inte behöver arbeta heltid för att möta deadlinen. Detta kan dock också vara en del av en större helhet som man skapar som ett modulärt system för att kunna använda i andra sammanhang, I så fall behöver man inte genast få betalt för hela arbetsinsatsen, utan man kan anse att den betalar tillbaka sig senare. Däremot verkar det inte finnas mycket spelrum för att flera skall arbeta i projektet, då ersättningen för projektet ändå är så pass liten. Vi anser också att man kan starta med reparationsmodulen parallellt med huvudprojektet.
Intermediate COCOMO, d.v.s. mellannivån av ursprungliga och föråldrade COCOMO-modellen från 1981, beräknar mjukvaru-utvecklingsinsatsen enligt programstorlek i tusen rader källkod och ett antal subjektivt uppskattade kostnadsdrivare inom produkt-, hårdvaru-, personal- och projektattribut.
COCOMO-formeln baserar sig på tanken att arbetsinsatsen för att utveckla system kan antas växa fortare än systemets storlek ökar.
Metodens brister och graden av korrekthet hos estimaten:
Uppskattning av parametrar
Det är svårt att uppskatta hur man skall välja parametrarna för modellen, redan genom att ändra en parameter fick man en förändring i medeltal på 5 dagar. Den ännu mer viktica KLOC kan vara svårt att uppskatta, speciellt i början av projektet då resursplanering och budgetering är viktigt.
Modellen
Också modellen har visat sig innehålla brister, enligt COCOMO II hemisdan *, så fast man visste den exakta KLOC så visade sig metoden 32% av fallen vara 20% missvisande.
För att få bra estimationer med denna modell måste man anpassa metoden till den gällande organisationenn genom att använda historiska data, som inte alltdi finns tillgänglig, speciellt inte i början av nya typer av projekt och kanske t.o.m. med ny personal. *) http://csse.usc.edu/csse/research/COCOMOII/cocomo81.htm
(hämtad från Wikipedia)
Som det syns i tidsestimenringen så verkar de olika projekten vara lite snålt tilltagna för att man genast skall få en vinst från projektet, men å andra sidan så kommer projektet att bringa in 15000£ varje år som egentligen kan anses vara en del av detta projekt. Därför kan det anses vara en investering att ta hand om detta projekt fastän det inte i början verkar bli lönsamt. Som vi har tänkt oss skall huvudprojektet ta ca 1 månad i anseende och sysselsätta två arbetare på heltid. Reparationsmodulen i sin tur verkar bli ett mindre projekt som en person själv får ha hand om och som inte behöver arbeta heltid för att möta deadlinen. Detta kan dock också vara en del av en större helhet som man skapar som ett modulärt system för att kunna använda i andra sammanhang, I så fall behöver man inte genast få betalt för hela arbetsinsatsen, utan man kan anse att den betalar tillbaka sig senare. Däremot verkar det inte finnas mycket spelrum för att flera skall arbeta i projektet, då ersättningen för projektet ändå är så pass liten. Vi anser också att man kan starta med reparationsmodulen parallellt med huvudprojektet.
Intermediate COCOMO, d.v.s. mellannivån av ursprungliga och föråldrade COCOMO-modellen från 1981, beräknar mjukvaru-utvecklingsinsatsen enligt programstorlek i tusen rader källkod och ett antal subjektivt uppskattade kostnadsdrivare inom produkt-, hårdvaru-, personal- och projektattribut.
COCOMO-formeln baserar sig på tanken att arbetsinsatsen för att utveckla system kan antas växa fortare än systemets storlek ökar.
Källa för värden använda i estimeringen: http://en.wikipedia.org/wiki/COCOMO.
Metodens brister och graden av korrekthet hos estimaten:
Uppskattning av parametrar
Det är svårt att uppskatta hur man skall välja parametrarna för modellen, redan genom att ändra en parameter fick man en förändring i medeltal på 5 dagar. Den ännu mer viktica KLOC kan vara svårt att uppskatta, speciellt i början av projektet då resursplanering och budgetering är viktigt.
Modellen
Också modellen har visat sig innehålla brister, enligt COCOMO II hemisdan *, så fast man visste den exakta KLOC så visade sig metoden 32% av fallen vara 20% missvisande.
För att få bra estimationer med denna modell måste man anpassa metoden till den gällande organisationenn genom att använda historiska data, som inte alltdi finns tillgänglig, speciellt inte i början av nya typer av projekt och kanske t.o.m. med ny personal.
*) http://csse.usc.edu/csse/research/COCOMOII/cocomo81.htm